Columbia Kermit/kermit.zip/newsgroups/misc.20000114-20000217/[e-mail] _Tue Jan 25 22:57:51 2000.msg

Internet Message Format | 2020-01-01 | 5KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id WAA06280
    for <[e-mail]>; Tue, 25 Jan 2000 22:57:51 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id WAA22027
    for [e-mail]; Tue, 25 Jan 2000 22:32:45 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Joe Doupnik)
Subject: Re: Case Study #10: Atomic File Movement
Message-ID: <[e-mail]>
Date: 25 Jan 00 20:30:49 MDT
Organization: Utah State University
To: [e-mail]

In article <86llha$40u$[e-mail]>, Mark Sapiro <[e-mail]> writes:
> Frank posted a tutorial on the features in C-Kermit for "atomic"
> file movement.
>
> I won't quote it here as it is readily available at
> http://www.columbia.edu/kermit/case10.html
>
> It seems to me however, that there must still be a window, albeit
> a small one during which a connection can be lost and the sender
> will believe the file has been successfully sent and the receiver
> will not or vice versa.
>
> I don't know the details of the protocol well enough to know exactly
> what scenario can occur, but I assume the sender sends a "file complete"
> packet of some kind.  Perhaps this packet gets lost when the connection
> goes down.  The sender may assume the file is successfully sent, but
> the receiver doesn't know it.
>
> Or perhaps the sender needs an ACK to this packet which the receiver
> sends and this is the packet that is lost.  Then the receiver knows
> it has received the whole file, but the sender doesn't.
>
> Am I missing something here, or is this a problem?
>
> --
> Mark Sapiro <[e-mail]>       The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
-----------
    May I relay a short story on this subject? It pervades networking
and most other two party exchanges. Good, it makes a nifty one to tell
the person next to you on the plane.
    Once upon a time there were two armies fighting a war. One army
was in a valley, the other was split on two hilltops. The hill army can
win if, and only if, the two components can attack in unison. Naturally
they send message back and forth "Let's attack at noon" etc. They may
be intercepted, faked, changed, misunderstood, and anything else we can
imagine to keep the guy next to us occuppied thinking.
    The question is, can the hill army be guaranteed to win? If so
what are the vital components of the messages passing back and forth.
    This problem is stated and discussed famously by Andrew Tanenbaum
in his book "Computer Networks." The answer is there is no guarantee,
there is no finite sequences of messages that clinch the mutual decision.
It is a tail recursion of "how do I know that they know that I know that
they know, etc"  If there were a last required message to do the deed
then it could be lost/garbled/faked, and confirmation would be needed.
Thus there isn't a last required message.
    With that there is no "closed form" solution in any protocol at
all that guarantees that what was sent is what was received and both sides
know it firmly. Only approximations exist, even if many or all messages are
delivered and understood correctly.

        The Kermit protocol has an end of file packet, signifying what it
says. It requires and ACK before the protocol will proceed to the next
thing to do. The ACK is well protected, but cannot be perfectly protected.
It can be lost and the EOF can be repeated, etc. Successful reception of
the ACK tells the file sender the receiver is pleased, but of course the
file receiver won't know that until new work arrives. Here progress is
implied by a rigid set of rules concerning what can be done next, and
reception of the next thing to do implies the preceeding was completed
by both ends. Or it could result from an error implementing the protocol
or even a fortutitious garble on the wire which creates just the right
message by mistake.
    Thus sending the ACK to EOF tells the receiver to keep the file and
await new things to do. The file transmitter may miss it and keep trying until
tired. The two perspectives may differ even though the file has been moved.
The two perspectives will agree if the ACK is not sent; it will be "not done
yet."
    That's my story for tonight.
    Joe D.